Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@api/spec/packages/aip-client-javascript/src/models/schemas.ts`:
- Around line 5188-5193: The invoice schema only includes standardInvoice in the
discriminated union, so credit_note payloads cannot be matched and the
credit-note branch is unreachable. Update the invoice
z.discriminatedUnion('type', ...) to include creditNoteInvoice alongside
standardInvoice, and ensure the credit note schema has its own unique
z.literal('credit_note') discriminator rather than sharing the standard type.
Keep the change localized to the invoice and creditNoteInvoice schema
definitions so the union resolves correctly by type.
- Around line 4758-4796: The invoice schema still excludes credit notes, so
update the union wiring around invoiceType and invoice to include credit-note
support. Add creditNoteInvoice to the invoice discriminated union alongside
standardInvoice, and extend invoiceType so it accepts the credit note variant as
well; use the existing invoiceType, invoice, standardInvoice, and
creditNoteInvoice symbols to locate the relevant schema definitions.

In `@api/spec/packages/aip-client-javascript/src/models/types.ts`:
- Around line 3311-3312: The `detailed_lines` field documentation in
`InvoiceLine` and `InvoiceLineInput` still mentions the removed `status` field,
so update both comments to describe the actual condition under which the array
is present. Use the `detailed_lines` property declarations in `types.ts` to
locate the stale wording and replace it with accurate SDK docs that no longer
reference `status`.
- Around line 2864-2865: The credit-note invoice variant is using the same
discriminator as StandardInvoice, which makes union narrowing and parsing
ambiguous. Update the credit-note branch in types.ts so the Invoice union has
its own unique discriminator value on the type field, and make sure any related
parsing/matching logic that keys off Invoice.type recognizes this new
credit-note discriminator alongside StandardInvoice.

In `@api/spec/packages/aip/src/invoices/invoice.tsp`:
- Around line 717-720: The documentation for the detailed sub-lines field refers
to a non-existent status property, so update the comment to describe the actual
presence rule instead. In the invoice schema around the detailed_lines
documentation, remove the outdated “Present when status is detailed or split”
wording and replace it with wording that matches the real model/implementation,
using the relevant field name as the source of truth.
- Around line 314-318: The doc comments on the invoice snapshot models are stale
and still refer to BillingParty inheritance even though the shapes are now
standalone. Update the summaries for the affected invoice snapshot types in
invoice.tsp, especially the snapshot-related declarations around
InvoiceCustomerSnapshot and the other cited snapshot model, so they describe the
actual standalone customer/billing snapshot data and any usage attribution
fields without mentioning extends or BillingParty.
- Around line 217-224: The invoice model’s `lines` field is underspecified for
the single-resource GET contract because it is marked optional even though
`BillingInvoice` always returns it. Update the `BillingInvoice`/`lines`
declaration in the invoice spec so the GET response reflects the actual
implementation by making `lines` required there, and only model omission
separately for any future list-shaped contract rather than weakening the current
`@visibility(Lifecycle.Read)` shape.

In `@api/v3/handlers/billinginvoices/convert.go`:
- Around line 25-37: The union dispatcher in convertInvoice only handles
billing.InvoiceTypeStandard, so it must be extended to map the other invoice
variants supported by the v3 contract. Update the switch on inv.Type() to add
the credit note case (and any other union members returned by GetInvoiceById),
convert each variant to its API shape, and populate the corresponding out union
setter instead of falling through to the unsupported invoice type error. Use the
existing helpers in this file, such as toAPIStandardInvoice and
out.FromBillingStandardInvoice, as the pattern for the new variant mappings.

In `@api/v3/handlers/billingprofiles/convert.go`:
- Around line 166-168: The address mapping in ToAPIBillingProfile is currently
guarded only by supplier.Address.Country, which causes valid supplier addresses
with line1, city, or postal_code but no country to be dropped. Update the
condition around the ToAPIAddress call so it maps any non-empty
supplier.Address, using the existing ToAPIAddress helper and the
supplier.Address fields as the source of truth, rather than requiring Country to
be set.

---

Nitpick comments:
In `@api/spec/packages/aip-client-javascript/src/models/operations/invoices.ts`:
- Around line 4-6: The request contract in GetInvoiceRequest is currently
declared as a type alias, but this plain object shape should use an interface to
match the repo’s TypeScript conventions. Update the GetInvoiceRequest definition
in invoices.ts from a type alias to an interface, keeping the same invoiceId
field so the request shape remains unchanged.

In `@api/spec/packages/aip/src/invoices/invoice.tsp`:
- Line 2: Remove the unnecessary `../invoices/index.tsp` import from
`invoice.tsp`; the file already defines `namespace Invoices`, so the import adds
no value and creates a circular dependency with `index.tsp`. Update
`invoice.tsp` to keep only its own namespace and related declarations, and
ensure nothing else in this file relies on symbols from `index.tsp`.

In `@e2e/billinginvoices_v3_test.go`:
- Around line 106-129: Broaden the coverage in the v3 invoice GET tests by
asserting the new contract fields exposed through GetBillingInvoice and
AsBillingStandardInvoice. In the happy-path subtest, add checks for at least one
invoice line’s quantity and unit_price, and verify the workflow payload is
present and well-formed on the decoded standard invoice. In the 404 subtest, go
beyond problem != nil by asserting concrete billing problem body fields on the
returned problem object so the error shape is validated too.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@api/v3/server/server.go`:
- Around line 325-330: Resolve the merge conflict in server.go by removing the
conflict markers and keeping both handlers wired correctly. In the server setup
near plansHandler and billingInvoicesHandler, preserve the required
planshandler.New contract by passing config.UnitConfig.Enabled along with
resolveNamespace, config.PlanService, and
httptransport.WithErrorHandler(config.ErrorHandler), and also keep the
billingInvoicesHandler.New constructor with its namespace, billing service, and
error handler. Ensure the block compiles cleanly with both constructors intact.